Telecommunications networks currently utilize signaling system 7 (SS7) signaling protocol to effect the exchange of information used to provide advanced intelligent network (AIN) and intelligent network (IN) services, such as number portability (NP) service and toll-free calling service. Such services will be referred to herein as “telecommunications services.” The data required to provide such telecommunications services may be stored in a service control point (SCP). A service may be invoked when a switch that originates a call determines that an IN or AIN trigger exists for the called party number, queries an SCP, and obtains a response including the requested information.
While such services are well developed in SS7 networks, such services have not been widely implemented in IP telephony networks, such as SIP networks. SS7 networks are not directly compatible with SIP networks because they each utilize different communications protocols. Communication between such networks may be necessary when a call originated by a SIP device in the SIP network requires information stored within the SS7 network.
One conventional method for retrieving telecommunications service information from an SS7 network for a SIP device is described in U.S. Pat. No. 6,785,374. The method includes sourcing a request for transaction capabilities application part (TCAP) information from a SIP proxy within a SIP network. This request is forwarded via a SIP message to an SS7/SIP signaling gateway to request that the SS7/SIP gateway formulate a TCAP query in the SS7 network. The request includes a SIP extension header that identifies the type of query being requested. In response to the request, the gateway transmits a TCAP message to an SCP within the SS7 network. The SCP then processes the request and returns a TCAP response to the SS7/SIP signaling gateway. The SS7/SIP gateway forwards the TCAP response to the originating SIP proxy.
One problem with such a technique is that it places the burden on the originating SIP proxy server of determining when to request a specific service from the SS7 network and identifying the service type. For example, in order to request LNP service, the SIP proxy server must be able to recognize that a called number has been ported. Similarly, in order to recognize a call that requires another service, such as toll free service, the SIP proxy server must include service logic that recognizes dialed toll free numbers.
Another problem with the method described in the '374 patent is that some calls may require multiple services, and the '374 patent fails to address this issue. For example, a call to an 800 number may result in the 800 number being translated into a routing number that requires number portability processing. Such a call would require the SIP proxy server to include service logic that recognizes the toll free number, the ported number, and that formulates two requests to the gateway for two different queries to the SS7 network. Requiring that SIP proxy server formulate two queries further increases the burden on the SIP proxy server. In addition, requiring that the SIP proxy server recognize and communicate the service request type to the SIP/SS7 gateway requires a non-standard SIP implementation and decreases the universal applicability of the gateway.
Accordingly, there exists a need for methods, systems, and computer program products for providing telecommunications services between a SIP network and an SS7 network in an efficient manner and that reduces the burden on SIP devices, such as SIP proxy servers.